Support — the service & messaging bounded context
The work that keeps every device running: service tickets with SLA frozen from the agreement tier at creation, and the customer ↔ RiverSync/partner messaging threads where alarms and appointments are handled in the conversation. A supporting subdomain — tickets and messaging tuned to the product, but a recognised pattern.
1Ownership & boundaries
Support owns the ticket, the visit and the thread — three records shared by three audiences (customer, assignee org, RiverSync). Its defining denormalization: ServiceTicket.Sla is copied from the device's agreement tier at creation, so a coverage move never rewrites open work.
Reads from: Devices (registry, alerts) · Coverage (SLA tier at creation; partner scope for queues) · Structure (visit site support-info, scope-gated) · Identity (engineer accounts).
2Ubiquitous language
The words this context uses — the same in code, conversation and spec.
3Aggregates & invariants
The consistency boundaries — one root each, guarding its invariants in a single transaction; cross-aggregate ties are by identity.
4Context relationships
How this context meets its neighbours, with the integration pattern named on each edge.
5Physical view — the service API
The deployment mapping: this context becomes the Support service. Paths relative to api.riversync.com/v1; access notation per the master.